Web services apparatus and methods

ABSTRACT

A Web Services directory includes at least one Business Entity object and at least one User object, wherein the at least one Business Entity object is arranged under the at least one User object.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of ProvisionalApplications Serial No. 60/406,391; 60/406,399; 60/406,325; 60/406,328;60/406,204; 60/406,205; and 60/406,319 each of which was filed on Aug.26, 2002 and the contents of each of which are incorporated herein byreference.

BACKGROUND

[0002] 1. Field

[0003] The present disclosure relates to UDDI Registry and Web Servicesin general, and in particular to method(s), apparatus and system(s) usedin giving practical effect to such services.

[0004] 2. Description of Related Art

[0005] UDDI (Universal Description, Discovery and Integration) is a setof Standards that have been defined to enable applications that use WebServices to quickly, easily and dynamically interact with one another.UDDI is intended to create a platform-independent, open framework fordescribing services, discovering businesses and integrating systemservices using the Internet, as well as an operational registry. Referto the web site www.uddi.org for further details.

[0006] A UDDI registry provides valuable support to systems structuredusing Web Services. Figure la illustrates schematically basic WebServices and UDDI concepts. FIG. 1b illustrates schematically asimplified protocol stack for the Web Services environment. UDDIprovides a repository for Web Services information and is itselfprovided by way of a Web Service.

[0007] UDDI enables applications to publish how they want to interact onthe web. Each ‘Web Service’ is a self-describing, self-contained,modular unit of application logic that provides some systemfunctionality to other applications through an Internet connection.Applications access Web Services via ubiquitous web protocols and dataformats, with no need to worry about how each Web Service isimplemented. Web Services can be mixed and matched with other WebServices to execute a larger workflow or business transaction.

[0008] The UDDI Standards describe a specific-purpose repository that isintended to manage descriptions of Web Service types, businessorganizations, and details about how to invoke the Web Services. TheStandards do not necessarily specify how the Standards should beimplemented, nor whether the implementation should include storage usinga database, a Directory or any other medium.

[0009] At a web site hosted by the organisation responsible for the UDDIStandards (http://www.uddi.org/fags.html) there are a number ofFrequently Asked Questions (FAQ). One of these questions is: “Can a UDDIregistry be built or based on LDAP?” In answer, this web site disclosesthat there is no formal relationship between UDDI and Directories. “TheUDDI specification does not dictate registry implementation details. TheUDDI specification defines an XML-based data model and a set of SOAPAPIs to access and manipulate that data model. The SOAP APIs define thebehaviour a UDDI repository exhibits. A UDDI implementation could bebuilt on an LDAP Directory as long as it conforms to the specifiedbehaviour. Thus far, all UDDI implementations have been built onrelational databases.”

[0010] It is to be noted that Directory technologies, such as X.500 andLDAP, are extensible, general-purpose data stores and their associatedlanguages that are most often used to manage users and resources. Theyare very well established technologies, widely adopted, and consideredvery stable and reliable.

[0011] However, implementing the UDDI Standards (available atwww.uddi.org) on a Directory requires the solving of a number ofproblems. The UDDI Standards leave many important issues unaddressed,such as:

[0012] The UDDI Standard defines a number of objects, some of which arerelated by a hierarchy, but UDDI does not define an all-encompassinghierarchy. For example. Business Service objects will come underBusiness Entity objects, and the Binding Template objects will comeunder Business Services. FIG. 2 illustrates an example of thishierarchy. Business Entity objects are denoted 21, Business Servicesobjects are denoted 22, and Binding Template objects are denoted 23. Itis also to be noted that TModel objects, denoted 24, for example, arenot hierarchically related to these objects. There are also otherconcepts such as Publisher Assertions, for example, which are notdefined hierarchically.

[0013] creating an efficient implementation of the requirement that auser be permitted to alter only those objects under his/her control,

[0014] creating an efficient implementation that would allow UDDIregistries to be distributed,

[0015] creating an efficient implementation which enhances aspects ofmanagement and performance of searching and update.

[0016] How to represent complex UDDI objects in a relatively efficientway. For example Business Entity, Business Service, Binding Templateand/or TModel have compound repeating elements. In turn these repeatingelements could contain further repeating elements. For example, aBusiness Entity may contain contacts and the contacts may containaddresses. Addresses may contain address lines and phone numbers. FIG.13 illustrates schematically a UDDI concept of a relatively complexobject-in a Business Entity. The Business Entity object 131, includes,for example a number of attributes 132, such as AuthorizedName,BusinessKey, and Name. The Name has one or more Name fields 133, such as‘text’ or this may be implicit in the ‘Name’ itself. There is also‘language’. There may be one or more of these fields 133.

[0017] How to provide for relatively rapid searching for a specificitems contained in repeating elements.

[0018] How to represent UDDI information and requirements in hierarchyof Directory objects,

[0019] How to manage deletion of UDDI objects and all their relatedinformation in an efficient manner, and

[0020] How to optimize construction of intermediate search resultcollections during search operations so that both Directory access anditerative in-memory operations are minimized, taking into account theDirectory storage medium limitations. In practice, Directory entries maybe stored and returned in arbitrary order, and Directory results may betoo large to sort.

[0021] How to represent the data concerning a Publisher Assertion, in anefficient way,

[0022] How to create an efficient implementation of PublisherAssertions, particularly with regard to the implementation of thefindrelatedBusiness method,

[0023] How to implement efficient searching of Publisher Assertions byrelationship,

[0024] How to manage the validity of a Publisher Assertion,

[0025] How to restrict the assertions created and deleted for a BusinessEntity are made by the owner of a Business Entity.

[0026] How to efficiently manage related collections of attributes, asdefined in the UDDI standard,

[0027] How to define attributes and objects to enhance the performanceof searching.

[0028] Various UDDI Schema have been proposed. However, none areconsidered to address at least the problems noted above. For example,one schema provides a relatively simplistic mapping of UDDI objects toDirectory objects, without necessarily having regard to the complexitiesand optimization to produce an efficient commercial implementation. Itis also unclear how a number of the UDDI services (the find_ series, inparticular) can be implemented efficiently in such a schema.

[0029] For example, FIG. 14 illustrates schematically a Novellrepresentation of a relatively complex object in a Business Entity. TheBusiness Entity object 141, includes for example a number of attributes142, each having a ‘type’ and ‘value’. As illustrated, there isAuthorizedName having a value ‘Bill’, BusinessKey having a value‘890.obale.890 . . .’, and Name having multi-values 143, 144 namely

[0030] en#CA

[0031] IN#CATS

[0032] The, UDDI (FIG. 13) and Novell (FIG. 14) example representationsare not considered to be efficient representations for Web Services.

[0033] Thus, there is a need to address the general problems noted aboveas well as other problems to provide a relatively extensible, efficientand reliable implementation of UDDI based on a Directory.

SUMMARY

[0034] A Web Services directory comprises at least one Business Entityobject and at least one User object, wherein the at least one BusinessEntity object is arranged under the at least one User object.

[0035] A Web Services system comprises a registry in which businessesmay register, the registry comprising a hierarchical directory includingat least one Business Entity object and at least one User object, the atleast one Business Entity object being arranged under the at least oneUser object and a storage system for storing business information andaccessible via the hierarchical directory.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Further objects, advantages and aspects of the present disclosuremay be better understood by reference to the following description ofpreferred embodiments taken in conjunction with the accompanyingdrawings, in which:

[0037]FIG. 1a illustrates schematically some Web Services and UDDIconcepts;

[0038]FIG. 1b illustrates schematically a simplified protocol stack forthe Web Services environment;

[0039]FIG. 2 illustrates schematically a Hierarchy according to therelated art;

[0040]FIG. 3 illustrates schematically a Directory Service Modelaccording to the related art;

[0041]FIG. 4 illustrates schematically the infrastructure components fora UDDI Service Model implemented using X.500 Directory technologyaccording to an embodiment of the present disclosure;

[0042]FIG. 5 illustrates schematically Service Projection, according toan embodiment of the present disclosure;

[0043]FIG. 6 illustrates schematically relationships between BindingTemplate and TModel, according to an embodiment of the presentdisclosure;

[0044]FIG. 7 illustrates schematically how a TModel creates arelationship between two entities, according to an embodiment of thepresent disclosure;

[0045]FIG. 8 illustrates a logical representation of a request to add aPublisher Assertion, according to an embodiment of the presentdisclosure;

[0046]FIG. 9 illustrates a logical representation of a constructor forUDDI data objects according to an embodiment of the present disclosure;

[0047]FIG. 10 illustrates schematically placing Business Entitiesobjects under User object(s);

[0048]FIG. 11 illustrates schematically placing Domain objects over Userobject(s);

[0049]FIG. 12 illustrates schematically an outline of the schemaaccording to an embodiment of the present disclosure;

[0050]FIG. 13 illustrates schematically a UDDI concept of a relativelycomplex object in a Business Entity according to the related art;

[0051]FIG. 14 illustrates schematically a Novell representation of arelatively complex object in a Business Entity;

[0052]FIG. 15 illustrates schematically the introduction of hierarchy inaccordance with an embodiment of the present disclosure for therepresentation of a relatively complex object in a Business Entity;

[0053]FIG. 16 illustrates schematically a Binding Template hierarchysub-structure according to an embodiment of the present disclosure;

[0054]FIG. 17 illustrates schematically a binding Template sub-structureflattened and/or merged; and

[0055]FIG. 18 is a block diagram of a computer system capable ofimplementing various aspects of the present disclosure.

DETAILED DESRIPTION

[0056] In describing preferred embodiments of the present disclosureillustrated in the drawings, specific terminology is employed for sakeof clarity. However, the present disclosure is not intended to belimited to the specific terminology so selected and it is to beunderstood that each specific element includes all technical equivalentswhich operate in a similar manner.

[0057]FIG. 18 shows an example of a computer system which may implementthe method and system of the present disclosure. The system and methodof the present disclosure may be implemented in the form of a softwareapplication running on a computer system, for example, a mainframe,personal computer (PC), handheld computer, server etc. The softwareapplication may be stored on a recording media locally accessible by thecomputer system, for example, floppy disk, compact disk, hard disk,etc., or may be remote from the computer system and accessible via ahard wired or wireless connection to a network, for example, a localarea network, or the Internet.

[0058] An example of a computer system capable of implementing thepresent method and system is shown in FIG. 18. The computer systemreferred to generally as system 180 may include a central processingunit (CPU) 182, memory 184, for example, Random Access Memory (RAM), aprinter interface 186, a display unit 188, a (LAN) local area networkdata transmission controller 190, a LAN interface 192, a networkcontroller 194, an internal bus 196 and one or more input devices 198,for example, a keyboard, mouse etc. As shown, the system 180 may beconnected to a data storage device, for example, a hard disk, 200, via alink 202.

[0059] The following summarizes some, of the salient features ofembodiments of the present disclosure and a few of the advantagesprovided thereby.

[0060] According to an embodiment of the present disclosure, arepository layer is created above users so each repository can be placedon a different server. This Repository layer includes one or moreDirectory nodes which collectively form the Directory pre-fix. This mayalso be known as ‘Domain’ or ‘Name’ of the Repository. An advantage ofthis is that it provides a single place to hold information about adomain. The name of this node represents the Directory prefix.

[0061] A user object may be created to hold the data representing a UDDIaccount. An advantage of this is that it provides a single place to holdinformation about a user/account.

[0062] Business Entity object(s) may be arranged under User object(s),Business Service object(s) under Business Entity object(s), and BindingTemplate object(s) under Business Service object(s). An advantage ofthis is that a repository or ‘domain’ layer above the user object layerenables a number of repositories to be posted or logically connectedtogether. The domain layer may be arranged in a number of levels, forexample having different countries, AU, US, EP, etc., organized bycontinent.

[0063] Another advantage is that this feature may be given effect by useof the Distribution features of an X500 Directory. For example, toimplement this, a ‘World’, or ‘Corporation’ Node is placed at the top ofthe virtual Directory tree, and a uniquely named Node is placed at thetop of each UDDI sub-tree (UDDI Name Space). While invisible to users,these ‘Node’ prefixes allow a UDDI repository to leverage Directorydistribution.

[0064] According to an embodiment of the present disclosure, theBusiness Entity objects can be made a child of the user object . Havinga user/account over the Business Entity, Business Service and BindingTemplate hierarchy gives the effect of each user having their ownsub-tree. This enhances manageability and security. The user is readilyrestricted to modifying and/or controlling only their own sub-tree. Thisalso enhances performance by making use of Directory sub-tree searchoperations

[0065] According to an embodiment, TModels defined by a user can be madechildren of the user object, thus makes security easy to implement. Thisenhances manageability and security since the user can only modifyand/or control their own sub-tree. It also enhances performance bymaking use of Directory sub-tree search operations.

[0066] An embodiment of the present disclosure represents a ‘mapping’ ofthe UDDI environment using X 500/LDAP Directory technology. Inparticular, the hierarchy structure of the X.500 and LDAP Directorytechnology has been found to be suitable to the UDDI environment.Careful design of additional elements (such as the user object) havemade the hierarchy even more suitable to the needs of the UDDIenvironment.

[0067] Throughout the present disclosure, the term Directory is toinclude X.500, LDAP and similar technologies; the term ‘Users’ isunderstood to also include ‘Accounts’ and visa versa; and the term‘Repository’ is understood to also include ‘Directory Pre-fix’, ‘Domain’and or ‘Node’ and visa versa.

[0068] Web Services were originally envisaged to be services betweenorganizations for example businesses, partners, customers, suppliers. Inthis context, UDDI was envisaged as a single repository for the servicesthese organizations offer.

[0069] It is now apparent that Web Services and UDDI are useful withinan enterprise to integrate applications inside an organization. It isalso apparent that Web Services and UDDI can be used to integrateproducts inside a product set from a given vendor. It is also applicableoutside the commercial environment, in areas such as governmentdepartments, large educational institutions, and many other instances ofnon-commercial entities.

[0070] The following description, although described with respect to anenterprise, has equal applicability to any type of environment andparticular applicability to the above-mentioned types of environments.

[0071] An enterprise UDDI registry can be a service that can be deployedwithin the Enterprise to publish information and services for internalconsumption. In addition, an Enterprise UDDI service may be leveraged toprovide other functions, such as configuration discovery for distributedapplications.

[0072] Web Services are being driven by the desire to quickly and easilyintegrate business processes, both internally and with partners. Onecomponent of using Web Services effectively is a public UDDI registrythat enables software components to dynamically discover and connect toappropriate services across the Internet. Web Services also offer thepromise of being able to integrate business processes within theEnterprise. In this case, the UDDI registry can become a piece of anorganization's infrastructure (e.g., an important Enterpriseapplication) and therefore provide the highest levels of security,performance, reliability and manageability. Directory technologyprovides an ideal foundation to support the stringent requirements of anEnterprise UDDI Registry.

[0073] An Enterprise UDDI registry can be defined as one that deliversStandards-compliant support for UDDI, but goes beyond it to address fourareas for deployment. These areas include SECURITY to restrict access toauthorized users only, DISTRIBUTION to support large deployments,MANAGEABILITY for a true production system and AVAILABILITY to meetservice level agreements.

[0074] Strong security may be an important requirement for certainEnterprise deployments. A public UDDI registry exists for the solepurpose of helping anyone discover available services. An UDDI registryexists for the sole purpose of having the right people discover theseservices. This is an important distinction.

[0075] An Internet UDDI registry is considered inappropriate fordeploying Web Services in an enterprise. For example, definitions of aWeb Service that interfaces to a payroll system or to an employees'benefits management application would not be posted to an Internet UDDIRegistry.

[0076] Security requirements may also mean that even an internallydeployed UDDI registry provide strong access controls. This is because aUDDI registry essentially presents a tutorial on what can be done andhow to do it. A UDDI registry provides a business-level description ofany available Web Service and directions to the WSDL that completelydefine the programmatic interface to those services. This provides ahigh-productivity tool for application developers, as well as hackers.

[0077] Accordingly, it is desirable to restrict access to interfacedefinitions for financially sensitive or confidential (such as medicalrecords) systems. Even within the development organization, it may bewise to restrict access to information about specific Web Services tothose authorized.

[0078] Using an unsecured UDDI registry within the enterprise, or withselected business partners through an extranet, could be extremelyrisky. Thanks to freely downloadable tools, people with relatively lowlevels of expertise can gain access to and use Web Services. Any trueEnterprise solution can implement a standard UDDI service with theability to transparently control access to information about WebServices.

[0079] With regard to DISTRIBUTION, in many cases, the initialdeployments of UDDI registries will be on a small scale. However, as WebServices requirements grow, large deployments will become more common.In addition, registry usage and deployments will accelerate with thediscovery of new functions for UDDI registries.

[0080] Larger implementations, and use within geographically distributedorganizations, will drive implementation of multiple UDDI registrieswithin a single organization. The evolution towards distributedregistries makes it critical for any individual registry to be able tointeract dynamically with other registries to service their requests.Once established; inter-registry communications could be extended beyondthe firewall to include registries at trusted business partners, or evenwith Internet UDDI registries.

[0081] There are considered to be two basic approaches to addressing theneeds for inter-registry communication. One approach is REPLICATION inwhich the same entry namespace exists on multiple servers. Anotherapproach is DISTRIBUTION in which interconnected servers have differententry namespaces, yet they operate as one logical service.

[0082] Although these two approaches may often be confused as beingsimilar, they are quite different.

[0083] In a REPLICATION approach, information is duplicated in everyserver that may need to look it up. This is a relatively simple, evensimplistic, solution, but it introduces requirements to synchronizeupdates, and it will, by definition, increase network congestion as thenumber of registries and the volume of their contents grow. Replicationtechniques are best suited for environments where the number of serversis low, the volume of information is low and changes are infrequent. Forenterprise deployments, replication is most useful to maintain backuprepositories in a fail-over environment. Keeping geographically orfunctionally distributed servers synchronized is very difficult usingreplication techniques.

[0084] In a distribution approach, information is logically representedon each participating server, but only stored in a single registry.Queries are distributed to the other registries only as required. Theinformation returned is thus guaranteed to be current. This provides asingle point of update and eliminates the problems of synchronizationand bandwidth consumption inherent with replication techniques. Truedistribution is considered to be one answer for scalable connectivitybetween servers.

[0085] For an Enterprise UDDI Registry, there are two scenarios in whichdistribution will generally be used. The first is for organizations withgeographically separated offices, each generating new UDDI entries andconsuming UDDI services. While it might be possible to run a singlecentralized UDDI registry, bandwidth restrictions and time zonedifferences frequently make this difficult to the point of beingunworkable.

[0086] A distributed registry provides a flexible, scalable solution. Inthis scenario, each participating office has a separate registry, andeach registry views the others as a logical part of its own content. Theregistry service takes care of all the connectivity details, andcustomers need not be concerned with geography.

[0087] The second scenario occurs when an enterprise needs to connectits internal UDDI system to that of a trusted partner, or publicInternet registry. In the case of a public registry, in particular,replication is problematic. Internet registry operators may be unwillingto replicate parts of their registry to the enterprise's internalregistry. Again, a distributed approach is one answer. At present, thereare no UDDI Standards for distribution and the proposals for replicationare considered complex. One solution would provide the benefits of aUDDI distributed approach without requiring modifications to thestandard.

[0088] With regard to manageability, as a component performingmission-critical functions within an enterprise, UDDI should meetperformance and reliability requirements. It should not just exist as aconvenient utility for developers. Read access by clients will be themost frequent and most time-critical usage of a UDDI registry.Performance is optimized for maximum throughput, and the response timesof lookup queries should not be affected by more complex searching.Performance should not suffer as the registry grows in size andcomplexity. The data store underpinning the UDDI Registry should beindustrial strength and fully support transactions and automaticrecovery. In addition, the UDDI servers should have a high degree ofavailability and support features such as network fail-over and hotstandby. System Administrators should have capabilities to make the UDDIregistry easy to maintain, monitor and control. These capabilitiesinclude DYNAMIC CONFIGURATION to change controls, rules and settingswithout taking the service offline, ONLINE BACKUPS AND TUNING for highavailability, ADMINISTRATIVE CONTROLS to stop “trawling” of the registryand prevent denial-of-service attacks, MONITORING via SNMP or othertypes of alerting mechanisms, AUDITING AND DIAGNOSTICS with separate logfiles for security, statistics, queries and update information andDEPLOYMENT options to support replication, distribution and routing.

[0089] Many developer-focused UDDI registries have been introduced.These provide useful capabilities for small development teams, but arenot true production quality systems. Web Services deployments aregrowing rapidly and there is a corresponding need for anEnterprise-quality registry that can scale rapidly to support ongoingWeb Service deployments.

[0090] A UDDI registry provides a service. This service will be reliedon by many applications. In the case of on-line businesses, it may beimportant that this service be ever present. For example, a UDDIregistry may be required to provide service level agreements of 99.99%availability. In order to facilitate this level of availability, theUDDI registry may be replicated across two or more machines, andmechanisms provided to make certain that the machines are keptsynchronized, and that, should any of the machines become unavailable,any incoming queries are automatically routed to an available machine.

[0091] As has been pointed out, UDDI may be considered as effectivelyanalogous to phone directory service. As such, the Directory model ofinformation storage is a perfect base on which to build a UDDI registryservice. The Directory model has been evolved and developed for thespecific needs of Directory-based services, with the security,scalability and reliability needed for enterprise level deployment.

[0092] Most of the items described above are implemented at the servicelevel, rather than at the data storage level, in applicationarchitecture. Relational databases (RDBMS) are generic toolkits uponwhich many different kinds of applications can be built. RDBMSimplementations concentrate on providing solid data access functionalityrather than extra service functions that are required in the endapplication.

[0093] The Directory Service architecture shown in FIG. 3 illustratesthe separation of a Service Layer 31 from the other components.Encapsulating the interface functions into a Service Layer 31 results inreusable service infrastructure components. An excellent example of thisis a web server. A web server provides a collection of functions (HTTPaccess, CGI processing and so on) that together make up a service usefulenough to build into a standalone component. In the same way, theDirectory Service model has been developed to supply the functionsrequired by a specific type of application. Directory technologiesprovide the underpinning for many mission-critical applications in thearea of authentication and authorization.

[0094] UDDI may be viewed as analogous to another kind of DirectoryService. It may then be seen that many of the implementation problemsposed by UDDI can be solved by using Directory technologies. Forexample, Directories are optimized for extremely efficient find andsearch operations that are very common for UDDI phone Directoryoperations.

[0095] It has already been noted that a UDDI service should offer strongsecurity, distribution and manageability capabilities if it is to bedeployed successfully in the Enterprise. These are the very sameattributes which have already been built into Enterprise-strengthDirectory Services solutions.

[0096] One way to construct an Enterprise UDDI registry is to extend theexisting Directory infrastructure, which has been tried and tested inhigh-performance, real-world applications.

[0097] The Directory Services architecture provides the optimal vehicleto implement an Enterprise UDDI registry. This combination supports thecapabilities necessary for success. The UDDI Service as illustratedschematically in FIG. 4 identifies components which may be implementedfor this infrastructure. UDDI SEMANTIC BRIDGE 41 is a service componentthat mediates between the SOAP implementation 42 of UDDI and the LADPinterface 43 supported by Directory 44. Directory 44 deliversinformation access with supporting security controls, distributionmechanisms, and administration capabilities. RDBMS 45 provides theunderlying physical data management, transactional integrity and backupand recovery mechanisms.

[0098] UDDI registry products may be built directly on RDBMS technology.Relational Databases, although very useful and strong in many ways, donot by themselves meet the requirements unique to Directory processing

[0099] It would be possible to build a Directory-type application fromscratch, utilizing an RDBMS or other data storage system underneath.However, this may not be the most efficient approach.

[0100] An alternative approach is to apply the Directory Service modelto deliver a UDDI registry and supply the functions required for thisspecific type of application. Even more functions required for a UDDIregistry could be supplied by modern, industrial-strength DirectoryServices. A UDDI registry may be viewed as a Directory Service withspecialized communications and APIs. Delivering UDDI services on aDirectory could provide the requisite security, distribution andmanagement capabilities without having to modify the UDDI Standards togain the benefits.

[0101] A careful design of the data representation would be beneficialto give the functionality and performance required of a UDDI repository.

[0102] The following description refers to various UDDI concepts. A moredetailed description of these UDDI concepts can be gained by referenceto the UDDI specifications (http://www.uddi.org/specification.html).

[0103] A schema, in Directory parlance, is a description of the dataelements that can be stored in the Directory, and how those elements maybe connected together. This includes descriptions of each of thepossible attributes (an attribute holds a single piece of data),descriptions of the various objects (an object is a collection ofattributes), and specifications of the possible object hierarchies. Theparticular Schema notation used in this specification is the one used byeTrust Directory, a product of Computer Associates International Inc.‘eTrust’ is a product name and trademark of Computer AssociatesInternational Inc. Of course, other Schema notations my be used.

[0104] The present disclosure describes a Schema used to implement aUDDI repository using a Directory as the data store. There are a numberof concepts involved in this Schema. There are also a number oftechniques used to enhance the operation of the UDDI implementation. Thefollowing is a brief description of some of these concepts. A moredetailed description of these concepts and techniques will be describedlater below when describing embodiments of the present disclosure.

[0105] The present Schema is designed to provide optimized operation.The present Schema design, which includes the definition of Attributes,Object Classes, Entries and the Hierarchy, is embodied in a manner thatenhances operation. The present Schema design provides significantadvantages in, at least, security, performance, manageability, anddistribution.

[0106] The hierarchy of the system will now be described. An X.500Directory supports distribution internally, providing a distributed UDDIrepository without any coding at the UDDI level. A level divides thecontents of the repository. The (optional) domain level of this schemaprovides that level, each domain entry, and all of the entries below it,can be placed on a separate Directory server transparently to theUDDI-level programming. FIG. 11 illustrates an embodiment of this aspectof the present disclosure. This will be described in more detail laterbelow.

[0107] According to an embodiment of the present disclosure, a userobject is placed over the business and TModel objects. The user objectprovides a place for the storage of information relating to the user. Italso provides an anchor point for all of the data published by the user.FIG. 10 illustrates an embodiment of this aspect of the presentdisclosure. This will be described in more detail later below.

[0108] Security is facilitated in this domain/user hierarchical system.A UDDI implementation can enforce that a user has control over theirsub-tree of data objects.

[0109] Searching for user controlled entries is provided. Searching fordata controlled by this user can be enhanced by using a sub-tree searchunder the user object.

[0110] It is possible to find a business by specifying, for example, aTModel that occurs in a Binding Template. This equates to “finding x byfinding one (or more) of its children”. In other words, a query may be“find all businesses which have a service which has a Binding Templatewhich references this TModel”. Such queries are done by finding the DN(Distinguished Name) of the descendent object, and discarding theunwanted levels, to yield the DN of the Business Entity. It is alsopossible to do duplicate elimination in this manner. This find featurecomes about due to the hierarchical nature of the structure of thepresent disclosure.

[0111] Searching may be performed using attributes unique to an objectclass. This is an optimization that has two advantages. This simplifiesthe writing of searches, and yields superior performance through theelimination of ‘weak’ clauses. A ‘weak’ clause is a part of a filterthat returns a large number of entries, or which refers to an attributethat is part of many entries. A design which used the same attributename for every Name would have two choices when searching, for aBusiness Entity by name: it includes the object class in the search orfilter the results of the search. The former is only possible ifbusiness names had a unique object class, and even so, object class is aweak clause, incurring more overhead. The latter means extra code andthe potential for returning a result list much larger than the desiredresult.

[0112] For example, consider a company called “McKenna's TestingServices” which offers a wide range of Web Services, all of whichinclude “McKenna's” in their name—a search for business entities with“McKenna's” in their name would return intermediate results for all ofthe services as well. These intermediate results may be eliminated, butdealing with them reduces performance.

[0113] It is preferable to be able to specify an attribute name in asearch and have that attribute name uniquely identify the object classbeing sought. To continue the example above, the search is much simplerif we can specify:

(euBusinessEntityName=McKenna's*)

[0114] Such a design produces strong searches, which are efficientbecause they are searching only the desired area. Strong searchesinclude searches which return a small number of entries. The Directorycan index the euBusinessEntityName attribute, and return results fromthat index—this produces good performance, and avoids handlingunnecessary intermediate results.

[0115] For simple queries, such a design means that a search for aBusiness Entity name is a single clause, rather than the compound thatmight be necessary in another design. Imagine if the name attribute werecalled euName, and the Business Entity name object were calledeuBusinessEntityName. That would yield a search like:

(&(euName=McKenna's*)(oc=euBusinessEntityName))

[0116] There is an even more simple design, wherein all names are storedin the same object class. This means that the search reduces to(euName=McKenna's*) again, but now we wade through results for allnames, trying to locate those which have a parent object that is aBusiness Entity—this last design would yield potentially poorperformance, and rather more complex programming.

[0117] Shadow attributes may be used for case-sensitivity. It is farfrom trivial to provide both case-sensitive and case-insensitivesearching using a single index. One option is to indexcase-insensitively, then scan the results case-sensitively. Anothersolution here is to index the original data case-sensitively, and to adda second attribute (in which the same data is stored) which is indexedcase-insensitively. Then all that is required is to choose theappropriate attribute to search depending on the find qualifiers.

[0118] Every attribute in this design may be single-valued. This allowsefficient indexing, higher performance, and stronger searches.

[0119] Using multi-valued attributes makes ambiguous searches possible.That is, it is possible to get search results which arecounter-intuitive, and unintended. Imagine a multi-valued numericattribute, called ‘n’, and an entry which contains this attribute withthe values 2 and 5; this entry will be returned in response to a search(&(n<3)(n>4)), which is not something that would be readily anticipated.

[0120] Single-valued attributes are one of the techniques used forstrong searches. A strong search is one which can eliminate the majorityof candidate results through the index. Strong searches are a key toimproved performance.

[0121] Aliases may be used for service projection. This is a significantbenefit of using an X.500 Directory as the data store. A serviceprojection can be represented neatly using an X.500 alias. This has themajor advantage of guaranteeing data integrity. The alias accesses theoriginal data, so any change to the original is instantly reflected bythe alias. If the Directory implementation supports alias integrity,then when the original entry is deleted the alias vanishes withoutadditional work.

[0122] Publisher Assertions are one of the least clearly definedelements in the UDDI Standard, and they require careful design. Aninappropriate implementation could readily yield poor performance.

[0123] Because the most common use of Publisher Assertions is thefind_relatedBusiness API, which is searching for all the completedPublisher Assertions relating to a specified Business Entity, it is gooddesign to place each assertion under a Business Entity to which itrefers.

[0124] By calculating the status of the assertion, and storing it in theassertion object, it is possible to restrict a search to completedPublisher Assertions. This means that the results returned will notcontain spurious references that are to be removed.

[0125] Storing the relationship object as an auxiliary class allows thesearch to eliminate any assertion which has an unwanted relationship. Ifthe relationship were stored as a child object, it would not be possibleto write a single search that would address both the relationship andthe assertion completion status.

[0126] UDDI keys may be used for naming where present. UDDI defines keysfor many of the important object classes, and these keys are specifiedas being guaranteed to be unique. This means that the keys can be usedas the naming attributes for the objects. Using the UDDI keys as thenaming attributes means that there is no need to attempt resolution ofnaming clashes—that would be required if, for example, the default namewere used as the naming attribute for a Business Entity.

[0127] Keys may be provided for naming where not present. That is, notall UDDI objects have defined keys. An example is Publisher Assertions.For these, the present system provides a key, using the same algorithmas is used for the UDDI-defined keys. This re-use of the idea means thatcode and structure written for the other objects can be re-used.

[0128] Where a series of UDDI objects are children of another object,and the order of the children is important (address lines, for example),the keys assigned to the child objects are arranged to be monotonicallyincreasing in value, so that sorting on the keys yields the desiredorder. This simplifies the process of ensuring the desired order.

[0129] Where practical, it is desirable that keys vary in alittle-endian manner. That is, the leftmost byte of the key varies mostrapidly, because that yields the best performance of indexing in theX.500 Directory being used as the data store.

[0130] The UDDI Standards define a number of sub-structures inside someof the main object types. In many cases these sub-structures areoptional, and may be repeated (they may occur zero, one, or more thanone times in the same object). A simple example is the namesub-structure, containing a string (the name) and a language identifier.The X.500 schema definition does not support the use of structuredattributes, so there is no immediately clear mapping of sub-structures.There are a few ways in which these sub-structures can be implemented inan X.500 schema.

[0131] One way is to concatenate the components of the sub-structureinto a single attribute, using a separator of some kind to divide thevarious elements. This may not be the optimum design choice, because itloses the ability to index or search the components separately, and itadds processing complications to handling the data.

[0132] In the present system, the particular design used to representsub-structures is chosen to maximise performance and manageability. Thedesign disclosed may use one or more of a variety of techniques torepresent sub-structures in a Directory. These techniques can besummarized in 3 categories.

[0133] One technique is that many of the sub-structures can be handledas child objects. Names are a good example: the Business Entity namesare stored as children of the Business Entity. Another example isdescriptions, where a separate Business Description object is a child ofBusiness Entity objects. FIG. 15 provides an illustration of anembodiment of this aspect of the present disclosure and will bedescribed in more detail below.

[0134] Another technique is flattening/merging. In cases where there maybe at most one relationship to another object, the attributes may becombined into a single object. In this case, the hierarchy is said to beflattened because two objects have been combined into one object. A newobject is said to be merged because the new object contains acombination of attributes from the combining objects. Preferably, thecontents of the Relationship Object are promoted to the Parent Object.

[0135] For example, FIG. 16 illustrates schematically a representationof a UDDI relationship diagram. FIG. 17 illustrates schematically aDirectory Hierarchy diagram where the Directory hierarchy has beenformed by a flattening of the UDDI objects.

[0136] By way of explanation, FIG. 16 illustrates Object 161 having arelationship Object 162 to Object 163.

[0137] In accordance with an embodiment of the present disclosure, wherethere is a one-to-one relationship, a ‘child’ can be promoted. In otherwords, that part of the hierarchy can be collapsed or flattened andobjects merged. The result is illustrated schematically in FIG. 17. TheParent Object 171 has contents A1, A2, An and has one or more children,Child Object 9n, with contents B1, B2, Bn, C1, C2 and Cn.

[0138] Another technique is splitting. For example, in one particularcase (the OverviewDoc sub-structure), a sub-structure contains anunrepeated element and a repeated element. The unrepeated element(OverviewURL) can be moved into the parent, while the repeated elementcan be made a child object.

[0139] Another aspect of the present disclosure is management. Deletinga TModel hides it from find_TModel but does not remove it from therepository. Accordingly, to implement the correct handling of TModels, ahidden flag may be implemented. The presence of this flag indicates thata TModel (or user object) is hidden. The absence of the flag indicatesthat it is not. This will be the case for the vast majority of TModels,so this approach is efficient. No space is occupied in unhidden objects,and no indexing is used either. The Directory will index only thoseentries which do have the hidden attribute. This also means that thesearch for unhidden TModels will be fast and efficient.

[0140] The X.500 Directory used as a data store encourages a designwhich does not store empty values. For example, a (optional) value whichis absent from the object is not stored in the Directory. This makesefficient use of storage space, and makes for stronger searches. Anysearch on an attribute need only consider those objects which have datafor that attribute.

[0141] The data hierarchy of the present system matches well with theintent of the UDDI Standard. When a request arrives to delete a UDDIobject, it maps directly to the deletion of a sub-tree in the Directory.For example, deleting a service includes deleting its names anddescriptions, and all of its Binding Templates. All of these arechildren of the service entry in the Directory. Accordingly, the presentsystem deletes the sub-tree from the service entry on down. This isreadily implemented, and efficient.

[0142] A domain is a name representing the base of a hierarchicalsub-tree. In X.500 terminology a domain is known as a context prefix. InLDAP terminology it is known as a suffix. Giving UDDI repositories adomain name allows use of true distribution (in the X.500 sense) of thedata in the repository. The UDDI Standard only supports replication. Byhaving the domain nodes, the present system can use Directorydistribution facilities transparently to the application.

[0143] For example, assume that an Enterprise deploys UDDI internally,but has two development sites. With this facility, they can deploy aUDDI server at each site, with distribution allowing each site totransparently view items published on both registries.

[0144] An advantage of this is that it allows distribution ‘for free’.For example, the UDDI server does not have to do any extra work and theDirectory system effectively links together islands of information.

[0145] Nothing in the UDDI Standards dictates how the user informationis stored. By creating user objects, all of the information relating toa user can be stored in a single object, and that object, can be used asthe root of the sub-tree holding all of the objects that the userpublishes. This makes the definition of security much simpler. Forexample, if the object under consideration (be it business, service, oreven TModel) is underneath the user's user object, then the usercontrols it.

[0146] UDDI defines objects that contain repeating elements. Forbenefits such as performance, searchability and manageability theserepeating elements can be represented as child objects.

[0147] Storing repeating structured data as child objects allowsrepresentation of the data efficiently in a Directory, with each fieldindividually available (and indexed) for searching.

[0148] For example, Business Entity names can be stored as children ofthe Business Entity object. Another example is Business Descriptionwhich can be stored as children below Business Entity objects.

[0149] An advantage of this type of system is that it allows searchingfor a name (which is a common UDDI search), and the DN of the entrygives the DN of the object to which the name belongs.

[0150] UDDI defines redundant ‘container’ nodes (UDDI structures whichcontain only child sub-structures, rather than attributes). These can beremoved because they can be constructed at relatively low cost from theresults of a query. In some cases, attributes can be promoted from achild node to its parent, to remove the now-redundant child-node fromthe Directory representation.

[0151] For example, tModellnstanceDetails is not represented in theDirectory schema as it contains no attributes. instanceDetails is notrepresented in the Directory schema as its attributes were promoted intothe tModelInstanceInfo parent, as were the attributes of its child,overviewDoc. The category and identifier bags are not represented in theDirectory, their contents are made children of the owner of the bag

[0152] An advantage of this is that it reduces the number of entries inthe Directory. In particular, it minimizes the depth of the DIT, whichcan improve performance.

[0153]FIG. 12 illustrates schematically a hierarchy structure accordingto an embodiment of the present disclosure. One or more Domain or Prefix121 are provided. Under each Domain 121, there may be one or more Users122. Under each User 122, there may be provided one or more TModel 123and one or more Business Entity (BE) 124. Under each Business Entity124, there may be provided one or more Publisher Assertion (PA) 125, oneor more Business Service (BS) 126 and one or more Service Projection(SP) 127. Under each Business Service (BS) 126, there may be providedone or more Binding Template (BT) 128. Aliases can be placed as requiredby a particular implementation. For example, Service Projectionobject(s) (shown as a triangle in FIG. 12) may stem as an alias fromBusiness Entity object(s).

[0154] The advantages of this schema design as represented in FIG. 12will become apparent from a reading of the present disclosure as awhole.

[0155] Publisher Assertions are placed under the business entities towhich they refer because they are most frequently used in the context ofa find_RelatedBusinesses call, which specifies a business key and islooking for all the businesses related to that one via PublisherAssertions. The present system locates the specified business, thenreads all the Publisher Assertions underneath it (that are complete).This is a quick and efficient way of locating the relevant assertions.

[0156] An advantage of this is that it allows fast and efficientsearches. It also allows easy maintenance of data integrity. Forexample, when a business is deleted, any Publisher Assertions areautomatically deleted too.

[0157] TModels can be changed (or retired/hidden) by the user whopublished them. Placing them under the entry representing the user makesthe security simple. For example, if the TModel lies in the sub-treeunder the user entry, then it can be modified. If not, then it can not.

[0158] In more detail, if the DN (Distinguished Name) of the user tryingto make the change matches a prefix of the DN of the TModel, the entrycan be modified by that user, otherwise it can not. The Directory can beused to make this determination (Naming exception if the DN doesn'texist), or the UDDI server can do it.

[0159] When an object is deleted from the repository, the informationassociated with that object may also be deleted. This is greatlysimplified by the hierarchical design used according to embodiments ofthe present schema. When the object is deleted, the entire sub-tree ofwhich it is the root can be deleted, and this process can delete all(and generally only) the associated information. Deleting a sub-tree canbe performed bottom-up. Each entry can only be deleted when all itschildren are deleted. This is managed by listing all the children inreverse DN order. This guarantees deletion of the children before theirparents.

[0160] An advantage of this is that a sorted list method is analternative to the more complex use of recursion. Further, it isrelatively simple and memory-efficient. When all the entries in thesubtree are sorted by DN, and deletes are executed in reverse order,this guarantees that all children will be deleted before their parent.

[0161] For example, when a business service is deleted, the systemdeletes all the Binding Templates associated with it, their TModelinstance information, and the various associated category information.All this can be deleted by deleting the sub-tree of which the businessservice is the root.

[0162] Due to the hierarchy used in the design of this schema, the DN ofan object reveals the chain of ownership and control for an object. Notethat inference is also dependent on careful choice of naming attributes.

[0163] An advantage of this is that it can reduce the number of searchesor reads used to gather information. For instance, with search resultswhich are child objects (such as names), the DN of each entry revealsthe parent (e.g. the BusinessEntity) and the owning account.

[0164] For example, the DN of a business service reveals the business towhich it belongs, and the user who controls it.

[0165] Directories do not guarantee any ordering of the result. Whendealing with a complex result (such as a Business Entity and itsbusiness services, together with their appropriate names anddescriptions), the construction of the output can be simplified bytaking the results of the search and sorting them by DN. This organizesthem so that the construction of the results becomes relatively simple.Each object is constructed before its children, so it is easy to placethe children under their parent, so that the result for a business isorganized before its services. All the children of an object appearbefore the next object of the same type, all of the services for onebusiness before the next business appears. This also allows simplerecursive construction, because the same thing applies at each level.

[0166] An advantage of this is that it minimizes the number of passesthrough a list of raw entries required to construct the UDDI structures.

[0167] For example, after sorting, the result for a business, A, isfollowed by a result for its first service, AA, that service's name,then A's second service, AB, and its names, then a second business, B.

[0168] A search can also be carried out on children. For example, afrequent search request may be “finding x by finding one (or more) ofits children”. One of the ways a business can be found by a search is byspecifying, for example, a TModel that occurs in a binding template. Inother words, the query is “find all businesses which have a servicewhich has a binding template which references this TModel”. Thesequeries can be done by finding the DN of the descendent object, andchopping off the unwanted levels to yield the DN of the business entity.Advantageously, this also eliminates duplication. This search methodcomes about, in part, due to the hierarchy structure of embodiments ofthe present disclosure.

[0169] The use of guaranteed unique keys simplifies matters. The entirerepository can be searched for a single key, and uniqueness will assurethat there will either be no result (if that key is not present), or oneresult (if it is present). There is no need to be cautious aboutlimiting searches within the range of a parent. This yields enhancedperformance from the Directory, because it can use, database indexes totheir optimum.

[0170] An advantage of this is that it makes use of the fastest type ofDirectory queries. Another advantage is that the guaranteed unique namesmay be important if a given object is referenced from another.

[0171] A property of most indexing systems is that they are datadependent. If the data is “little endian” (the leftmost portion changesmost rapidly) that data tends to be spread and so the indexes can givemaximum performance. Conversely, if the data is repetitious, the indexesmay not be very effective. A UUID (Universally Unique Identifier)algorithm can be used which exhibits “little endian” qualities. Anadvantage of this is that it maximises Directory performance.

[0172] Keys may be added to derived objects. Where a repeating dataelement is made into a child object, there is a need to add a namingattribute, which will form the last arc of its DN. In a Directory, thenaming attribute is different from its siblings, since no two childrenof the same parent can have the same name.

[0173] Two kinds of keys may be used. For child objects which do notrequire order, UUIDs are used because these are guaranteed to be unique.Where order is important, keys with a monotonically increasing propertyare used to guarantee order.

[0174] In the UDDI Standard, a Business Entity can offer two kinds ofservices: those which it controls (represented in the repository bychild objects), and those which it offers an interface to, despite thefact that they are provided by another Business Entity. The latter arerepresented in the disclosed UDDI repository by aliases. An aliasprovides exactly the right features. For example, if the original object(service) is altered in some way by its owner (perhaps another BindingTemplate is added), then the object referenced via the alias “changes”too. Moreover, any search under the Business Entity for a service willyield both real and aliased services.

[0175] For example, aliases can be used for Service Projection, where aBusiness can point to a Service defined under another Business.

[0176] An advantage of this is that leveraging aliases allowsfunctionality that basically involves “an alternative name” to beautomatically provided. Furthermore, if the Directory supports aliasintegrity, then if the original Service is deleted, any projections areautomatically removed.

[0177] In the UDDI Standard there are a number of places in which we donot wish to have direct reference to another object; but rather anintermediate step—such as in the case of TModel instance information, orthe references to business entities in a Publisher Assertion. In thesecases, an alias would complicate the code. Accordingly, instead thepresent system may use a reference to the object. Because the presentsystem, according to an embodiment, guarantees that every object has aunique key, then that key behaves exactly as a reference, sometimesknown as a “foreign” key.

[0178] Attribute grouping can be performed using auxiliary object class.In handling Publisher Assertions there is a need for an ability tolocate a Publisher Assertion using those three attributes which uniquelyidentify the Publisher Assertion: the two Business Entity keys, and therelationship between them. However, the relationship is specified as akeyed reference, which is itself three different attributes: TModel key,key name, and key value. One way is to store this relationship as achild object of the Publisher Assertion. However, this may not allow themost efficient search for a specific Publisher Assertion. By making therelationship keyed reference an auxiliary class to the PublisherAssertion entry it is possible to search for all five attributes in asingle search, and thus isolate exactly the Publisher Assertion objectsrequired.

[0179] One design of this schema may use normal object-oriented designtechniques, and yield, for example, all keyed references having the sameattribute names. However, this design may make it more difficult andexpensive to isolate, for example, a Business Entity category keyedreference, and to avoid confusing it with a TModel category keyedreference. It may also make it necessary to include object class termsin the filter and such terms are weak (highly repetitious in therepository).

[0180] Giving, for example, every different kind of keyed reference adifferent object class and different attribute names, means that anysearch for a particular attribute name necessarily implies the objectclass. It also means that the Directory server can construct an indexthat only has entries in it for the specific kind of entry desired. Suchan index will be smaller and consequently faster.

[0181] For example, a search like: “euBusinessEntityName=Smith*” willconsult, the index for euBusinessEntityName, and so cannot be confusedby an entry containing Smith in an attribute called euTModelName.

[0182] There may well be a call for tools outside the scope of the UDDIStandard. Such tools may need to provide means of access beyond thosespecified in the UDDI Standard. To allow for such tools, this presentdisclosure defines abstract classes which bind all the object classesthat represent a single UDDI concept. This allows the definition ofsearches which can look at, for example, all names, or all keyedreferences.

[0183] For example, there is an abstract class euName which is thesuperclass of all the Name-type object classes, includingeuBusinessEntityName and euTModelName.

[0184] The UDDI Standard specifies that it be possible to search, forexample, names in both case-sensitive and case-insensitive ways. Thiscan be handled by indexing case-insensitively, and then retrieving theentries and checking them case-sensitively, but such an approach costsperformance. It is preferable in these cases to define a shadow fieldwhich contains the same data, but is indexed differently. Similarly,shadow attributes can be used for variations in language, e.g.diacritical marks.

[0185] For example, the euBusinessEntityName object class contains twocopies of each name. The first version is indexed case-insensitively,while the second is indexed case-sensitively. This allows theconstruction of a search filter which performs optimally no matter whichbehaviour is requested.

[0186] Every attribute (except object class) in this repository may besingle-valued. This makes it possible for the Directory to constructmore efficient indexes, and provide better performance in searching.

[0187] This also removes the possibility of false positive results insearching. For example, consider a search that looks for names whichbegin with “Fr”, and end with “nk”. One might expect this to yield(valid) entries with names like “Frank”. If, however, name is made amulti-valued attribute, one may well get an invalid entry with two nameslike “Fred” and “Tink”, because this one entry matches both criteriaspecified. By using single-valued names, each of which is a child objectof the entry, the spurious matching of “Fred” and “Tink” is eliminated.

[0188] Operational attributes are special attributes that are managed bythe UDDI application, but which are not seen by the user.

[0189] In the storage of UDDI data, it should be possible to have a wayto distinguish TModels which are in-use from those which have been“retired”. When a TModel is deleted, it may well still be used by manyentries, so it cannot be truly deleted. Instead it is hidden, whichmeans that it will not be returned as part of the results of afind_TModel call, but it can still be queried via a get_TModelDetailcall. This is implemented by use of an attribute called euHidden, whichis added to those TModels which are hidden. It may be beneficial andefficient to add a search step which eliminates any entry containing theeuHidden attribute to any filter searching for TModels.

[0190] In Directory implementations it is considered generally veryinefficient to have an attribute which is predominantly one value. Forexample, having a hidden attribute which is set to FALSE for 99% of theentries would produce poor performance—the index would be pretty muchunusable.

[0191] What is considered much more effective is to have the majority ofentries stored without the hidden attribute, and only add the attributeto those entries which are to be hidden. This has the additional benefitof not requiring the storage space to hold all those “FALSE” values. Nowthe filter for finding all those TModels which are not hidden becomes“(!(euTModel=*))”—which is a negation of an existence test, andexistence tests are rapid, especially when the attribute only exists ona small fraction of the entries.

[0192] An embodiment of the present disclosure will now be described forresolving the implementation and UDDI Standard's issues in the contextof a Directory. There are a number of elements to an X.500 schema. Theseelements include Attribute definitions, Object Class definitions andName Binding definitions. An Attribute definition specifies a singledata element, giving it a unique identifier (an OID), a name, and a datatype. An Object Class definition specifies a collection of attributeswhich is manipulated as a whole. It gives a unique identifier (an OID),a name, and a list of attributes; the attributes may be required oroptional. A Name Binding specifies part of a possible hierarchy. TheName Binding specifies one object class which may be stored underanother, and specifies the attribute (or attributes) of the child thatnames the child object in this context.

[0193] There are a number of find qualifiers which impose additionaldesign requirements. One find qualifier is case sensitivity forproviding the ability to search for text data in both case-sensitive andcase-insensitive manner efficiently. According to an embodiment of thepresent disclosure, case sensitivity can be resolved by providingadditional fields in the objects, indexed differently.

[0194] According to this embodiment, the textual data is stored twice inan attribute of type caseExactString, and in an attribute of typecaseIgnoreString. The find qualifier then determines which of the fieldsis searched, resulting in maximum performance.

[0195] For example, if a Business Entity has a name like “McKenna's IronFoundry Services”, then that string will be stored twice, once in afield that is indexed case-sensitively, and once in a field that isindexed case-insensitively—the stored data is the same, but the indicesgenerated by the underlying Directory are different.

[0196] Another issue involves implementing service projectionsefficiently. According to an embodiment of the present disclosure, thiscan be solved using the X.500 alias facility. There are a number of waysin which service projections may be handled. This embodiment of thepresent disclosure handles them by way of Directory aliases. This is aparticularly efficient way to implement them. It guarantees consistencyof the projection with the base service, because the base service isaccessed directly through the alias. It also guarantees that theprojection will vanish the moment the base service is deleted, thusensuring consistency.

[0197] For example, if a Business Entity called Williams AccountingServices publishes a Web Service called General Ledger Cross-Check, andit is desired to offer this same service under a second Business Entitycalled Williams Auditing Services, then this can be achieved by placingan alias entry under the second Business Entity. An inquirer enumeratingthe services offered by Williams Auditing Services will find the GeneralLedger Cross-Check service, just as it will find any services offereddirectly by Williams Auditing Services.

[0198] Another issue involves implementing keys efficiently. Accordingto an embodiment of the present disclosure, this is resolved using UUIDsfor external keys, and keys where order is unimportant. Sequentialnumbers may be used where order is important. Although keys arerepresented as strings, they are not truly text data. They are comparedwithout sensitivity to case or diacritic marks.

[0199] Externally-visible keys follow one set of rules. Whenimplementing a repository compliant with Version 2 of the UDDIspecification they hold UUIDs, compliant to ISO-11578. When implementinga repository to Version 3 of the UDDI specification they hold keystrings following the rules laid out in that version of thespecification.

[0200] Note that keys used internally to link elements together followanother set of rules. Those where order is unimportant use UUIDs. Whereorder is important, sequential numbers are used.

[0201] For example, a keyed reference that represents an element of acategory bag for a Business Entity called Williams Auditing Services,might reference a TModel with a key of12345678-1234-1234-1234-1234567890ab (UDDI v2). The order of the keyedreferences in a category bag is unimportant, but the keyed referencerequires a key to function as a naming attribute of the object. Thus wemight generate a UUID key for this object, something like87654321-4321-4321-4321-ba0123456789, and use that as the namingattribute in the Directory for this object.

[0202] Another issue is that data may be organized into domains if X.500distribution is desired. This is resolved according to an embodiment ofthe present disclosure by creating a repository layer above users soeach repository can be placed on a different server.

[0203] The UDDI Standard does not allow for the name space to bedistributed. This means that multiple UDDI registries can co-operatewith each other by replication or by transparently having the backenddata store managing the distributed name spaces.

[0204] Distributed name spaces can be facilitated by each repositoryhaving a naming pre-fix. This pre-fix is a set of nodes that define aDomain. These nodes can be considered a repository layer above each UDDIregistry. These nodes are placed above the user level.

[0205]FIG. 11 illustrates an example of such a node, called “Domain”110. Domain 110 is the Directory pre-fix and may include one or morenodes up to the root. Below the Domain 110, this example illustrates thearrangement of a number of users 112, 113 and 114, for example. Thenumber of Users arranged under a Domain 110 may vary according to theparticular configuration and/or use of the present system. There mayalso be a number of domains arranged depending on the particularconfiguration and/or use of the present system. In the example belowthey are referred to as repository objects, suggesting that theyrepresent separate physical repositories. Of course, this may notnecessarily be the case, depending on the configuration and/or use ofthe present system.

[0206] The repository object requires a naming attribute, but that isall. set object-class uddiObjectClass:400 =  { # repository - may beused to break users into groups  name = euRepository  subclass-of top  must-contain    euRepositoryName };

[0207] Distribution is an important concept in large-scale Directorydeployment, as it allows for data to be shared by multiple nodes withoutthe massive bandwidth overhead and synchronization problems ofreplication.

[0208] In one embodiment, ‘eTrust’ UDDI supports distribution using thecapabilities of the underlying eTrust Directory server, and in order forthis to work the schema has been structured accordingly, with allowancefor a virtual ‘Domain’ node(s) at the top of the tree hierarchy andunique Node identifiers or names at the top of each Node sub-tree (seeUDDI schema description below).

[0209] Furthermore, an eTrust UDDI server can be made‘distribution-aware’ through configuration. Two separate Directoryprefixes can be specified—one for searching and reading, and another forAdding entries. To deploy a distributed server, the underlying eTrustDirectory server agents are configured for distribution as per theeTrust Directory Admin Guide. Each separate eTrust UDDI node isconfigured with a unique Node name. The Search/Read prefix for each nodeis set to the ‘World’ or ‘Corporation’ node name. The Add prefix foreach node is set to the unique name of that Node.

[0210] In this way, each Node adds entries to its own Directoryrepository, but searches for entries across all Nodes via thedistribution features of the X500 Directory.

[0211] An example of a repository object might be:

euRepositoryName=Melbourne

[0212] Another issue involves organizing the data which is held aboutthe user. This can be resolved by creating a user object to hold thedata.

[0213] Although there is no user object specified in the UDDIspecification, such an object can be utilized according to an embodimentof the present disclosure. For example, a user object can be, amongother things, a storage point for user credentials, and an anchor pointfor publishing.

[0214]FIG. 10 illustrates an example of such an arrangement, called‘User’ 101. Below the user 101, this example illustrates the arrangementof other object(s), such as Business Entity object(s) 102, BusinessService object(s) 103 and Binding Template object(s) 104. The number ofBusiness Entity object(s) arranged under a user 101 may vary accordingto the particular configuration and/or use of the present system. Theremay also be a number of users arranged depending on the particularconfiguration and/or use of the present system.

[0215] The data elements held in the user object include the user key(used to provide a unique name for this user account), the user name,and the credentials (may be as simple as a password, or as complex as aPKI certificate). It may also contain an authorized name (identifyingthe person or role authorized to operate the user account). It may alsocontain a hidden flag used in handling the deletion of user accountswithout losing any TModels defined by the user. set object-classuddiObjectClass:401 = { # user account  name = euUserAccount subclass-of top  must-contain   euUserKey,   euUserName,  euCredentials  may-contain   euAuthorizedName,   euHidden };

[0216] An example of a user account object might be:

euUserKey=23456789-2345-2345-2345-234567890abc

euUserName=Grace

euCredentials=Amazing76sQ

[0217] (it is assumed in this example, that a simple userid and passwordsystem has been implemented)

[0218] Another issue involves representing the data concerning aBusiness Entity (an object class described in the UDDI Standard), in anefficient way. This is resolved according to an embodiment of thepresent disclosure by representing unique fields as attributes of theobject, and repeating elements as children.

[0219] The Business Entity object is a fundamental component of the UDDIStandard. Its content is defined by the standard, but many of itselements are repeating complex objects, which are not supported by X.500schema. Such elements are represented by a hierarchical arrangement.

[0220] The only required element in a Business Entity is the businesskey. Optional elements include an authorized name, an operator, and auser key (this last will be present in a Business Entity published by anormal user). set object-class uddiObjectClass:402 = { # BusinessEntity - details of an entity which provides services  name =euBusinessEntity  subclass-of top  must-contain   euBusinessEntityKey may-contain   euParentUserKey,   euAuthorizedName, };

[0221] The possible child objects of a Business Entity are: Name (anobject containing the name string and language code, keyed forordering); Description (an object containing the description string andlanguage code, keyed for ordering); Contact (a complex object—describedlater below); Discovery URL (an object containing the URL string anduse-type, keyed); Keyed References which are marked as category oridentifier information through choice of object class; and BusinessServices (described below)

[0222] An example of a Business Entity object might be:

euBusinessEntityKey=34567890-3456-3456-3456-34567890abcd

euParentUserKey=23456789-2345-2345-2345-234567890abc

[0223] Note that most of the apparent content of the Business Entityobject is actually stored in objects that are direct children of theBusiness Entity object

[0224]FIG. 15 illustrates, an example of the introduction of a hierarchyinto a sub-structure according to an embodiment of the presentdisclosure for the representation of a relatively complex object in aBusiness Entity. In FIG. 15, the multi-valued elements: For child 152Language en Name CA For child 153 Language IN Name CATS

[0225] are represented as children 152, 153 of the Business Entity151.There may be none or more children.

[0226] Another issue to be resolved is representing the data concerninga Business Service (an object class described in the UDDI Standard), inan efficient way.

[0227] This can be resolved according to an embodiment of the presentdisclosure by representing unique fields as attributes of the object,and repeating elements as children.

[0228] The Business Service can be implemented in at least two ways. Afirst is that the Business Service represents a single conceptualservice provided by the Business Entity, available through one or moreaccess routes, each of which was represented by a Binding Template. Asecond is that the Business Service is a grouping mechanism forservices, with the breakdown into individual services taking place atthe Binding Template level. In either case, the data fields are definedin the UDDI specification.

[0229] The elements of a Business Service are the business and servicekeys. The business key specifies the Business Entity which owns theservice. This is not necessarily the Business Entity under which it isdiscovered. A single service can be found under several businessentities, by way of service projections. The service key is the uniqueidentifier of the service throughout the UDDI repository. Both keys arerepresented as strings. set object-class uddiObjectClass:403 = { #business  name = euBusinessService  subclass-of top  must-contain  euBusinessServiceKey,   euParentBusinessKey };

[0230] There is no optional content of the Business Service object. Allother content consists of potentially repeating elements, and so isrepresented as child objects. The potential child objects of a BusinessService are: Binding Templates (see below); Name (an object containing aname string and a language code, keyed for ordering); Description (anobject containing the description string and language code, keyed forordering); and Keyed References marked as category information.

[0231] For example, a Business Service object might be:

euBusinessServiceKey=4567890a-4567-4567-4567-4567890abcde

euParentBusinessKey=34567890-3456-3456-3456-34567890abcd

[0232] Note that most of the apparent content of the Business Serviceobject is actually stored in objects that are direct children of theBusiness Service object.

[0233] Although, FIG. 15 illustrates an example of the introduction of ahierarchy into a sub-structure according to an embodiment of the presentdisclosure for the representation of a relatively complex object in aBusiness Entity, it is equally illustrative of an example of theintroduction of a hierarchy into a sub-structure according to anembodiment of the present disclosure for the representation of arelatively complex object in a Business Service. The Business Entity 151of FIG. 15 is equally applicable to a Business Service, with themulti-valued elements of the Business Service represented as children152, 153 of the Business Service 151. There may be none or morechildren.

[0234] Yet another issue involves representing the data concerning aBinding Template (an object class described in the UDDI Standard), in anefficient way. This is resolved according to an embodiment of thepresent disclosure by representing unique fields as attributes of theobject, and repeating elements as children.

[0235] The Binding Template represents a way in which a particularservice may be accessed. The only required elements of a BindingTemplate are its key and the key of the service to which it applies.Optional elements may include an access point or hosting redirector (theobject should have exactly one of these). If an access point is present,then the access point type should also be present. set object-classuddiObjectClass:404 = { # binding template  name = euBindingTemplate subclass-of top  must-contain   euBindingTemplateKey  may-contain  euParentServiceKey,   euHostingRedirector,   euAccessPoint,  euAccessPointType };

[0236] The possible child objects of a Binding Template are: TModelInstance Info (see below); and Description (an object containing thedescription string and language code, keyed for ordering)

[0237] An example of a Binding Template might be:

euBindingTemplateKey=567890ab-5678-5678-5678-567890abcdef

euParentServiceKey=4567890a-4567-4567-4567-4567890abcde

euAccessPoint=http://www.rsps.com.au/wsep

euAccessPointType=http.

[0238] Again, although FIG. 15 illustrates an example of theintroduction of a hierarchy into a sub-structure according to anembodiment of the present disclosure for the representation of arelatively complex object in a Business Entity, it is equallyillustrative of an example of the introduction of a hierarchy into asub-structure according to an embodiment of the present disclosure forthe representation of a relatively complex object in a Binding Template.The Business Entity 151 of FIG. 15 is equally applicable to a BindingTemplate, with the multi-valued elements of the Binding Templaterepresented as children 152, 153 of the Binding Template 151. There maybe none or more children.

[0239] Another issue involves representing the data concerning a TModel(an object class described in the UDDI Standard), in an efficient way.According to an embodiment of the present disclosure, this can beresolved by representing unique fields as attributes of the object, andrepeating elements as children.

[0240] A TModel represents an idea. That idea might be, for example, acategorization system, requiring the specification of values which maybe validated. Or it may be a specification of a data communicationprotocol. TModels are a flexible and powerful concept, and central tothe ability of UDDI to represent complex data in a way that can beaccurately queried.

[0241] The only required elements of the TModel object are a TModel keyand a name. These are represented as strings.

[0242] The optional elements of a TModel object are an authorised name,an overview URL (part of an Overview Doc object), a user key, and ahidden flag.

[0243] A hidden flag is a an element of the handling of the TModel. Thehidden flag is how the deleteTModel call is handled. When a TModel is“deleted” the hidden flag is added to the object. This means that theobject will not be returned to a findTModel call, but will be accessibleto getTModel calls. set object-class uddiObjectClass:405 = { # tmodel -a reference to an idea.  name = euTModel  subclass-of top  must-contain  euTModelKey,   euTModelName  may-contain   euAuthorizedName,  euOperator,   euOverviewURL,   euParentUserKey,   euHidden };

[0244] The possible child objects are: Description (an object containingthe description string and language code, keyed for ordering); KeyedReferences marked as category or identifier information; and OverviewDoc Description (an object containing the description string andlanguage code, keyed for ordering)

[0245] An example of a TModel could be:

euTModelKey=uuid:67890abc-6789-6789-6789-67890abcdef1

euTModelName=Corporate QA Policy

euOverviewURL=http://www.rsps.com.au/policy/ga.html

euParentUserKey=23456789-2345-2345-2345-234567890abc

[0246] Again, although FIG. 15 illustrates an example of theintroduction of a hierarchy into a sub-structure according to anembodiment of the present disclosure for the representation of arelatively complex object in a Business Entity, it is equallyillustrative of an example of the introduction of a hierarchy into asub-structure according to an embodiment of the present application forthe representation of a relatively complex object in a TModel. TheBusiness Entity 151 of FIG. 15 is equally applicable to a TModel, withthe multi-valued elements of the TModel represented as children 152, 153of the TModel 151. There may be none or more children.

[0247] Another issue involves representing the data concerning aPublisher Assertion (an object class described in the UDDI Standard), inan efficient way.

[0248] According to an embodiment of the present disclosure, this can beresolved by representing unique fields as attributes of the object, andusing an auxiliary class for the required relationship keyed reference.

[0249] A Publisher Assertion is an object representing a relationshipbetween two business entities.

[0250] The required elements of a Publisher Assertion are its key, theto and from business and user keys, the status, and the relationship.The relationship is specified as a keyed reference, and stored as anauxiliary class to the Publisher Assertion entry. The status is storedas a string, but draws its possible values from the Completion Statusobject. All the keys are represented as strings. set object-classuddiObjectClass:406 = { # publisher assertion - a relationship betweentwo businesses  name = euPublisherAssertion  subclass-of top must-contain   euPublisherAssertionKey,   euFromBusinessKey,  euFromUserKey,   euToBusinesKey,   euToUserKey,  euPublisherAssertionStatus }

[0251] There is no optional content in a Publisher Assertion, and thereare no child objects.

[0252] An example of a Publisher Assertion might be:

euPublisherAssertionKey=7890abcd-7890-7890-7890-7890abcdef12

euFromBusinessKey=34567890-3456-3456-3456-34567890abcd

euFromUserKey=23456789-2345-2345-2345-234567890abc

euToBusinessKey=09876543-6543-6543-6543-dcba09876543

euToUserKey=98765432-5432-5432-5432-cba098765432

[0253] euPublisherAssertionStatus=status:complete

[0254] Note that there will be an auxiliary class associated with thisentry; it will be of object classeuPublisherAssertionRelationshipKeyedReference, and will specify therelationship that is being asserted between the two business entitiesnamed. An example might be:

euPublisherAssertionTModel=uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

euPublisherAssertionKeyName=wholly-owned subsidiary

euPublisherAssertionKeyValue=parent-child

[0255] Another issue involves representing the data concerning a keyedreference (an object class described in the UDDI Standard), in anefficient way. This is made more complex, by the need to be able tosearch efficiently for particular collections of keyed references: thecategory bag on a Business Entity, for example.

[0256] This is resolved according to an embodiment of the presentdisclosure by creating an abstract base class to represent keyedreferences, and subclass it for each of the desired collections. Thecollections do not have a representation in the Directory. For example,they exist as nothing more than a group of keyed references of the samesubclass, existing as children of the same object. For example, thecategory bag of a Business Entity is the objects of classeuBusinessEntityCategoryKeyedReference which are children of thespecified Business Entity. Note that a Business Entity object can wellhave several keyed reference objects as children, with only their objectclasses making it clear which ones are part of the category bag andwhich are part of the identifier bag.

[0257] Keyed references are used in several places within the UDDI datamodel. They include a TModel key, a key name, and a key value. Two usesof keyed references are category bags and identifier bags. These bagsare collections of keyed references, and are important to searching. Ifthese bags were represented by objects containing undifferentiated keyedreferences, then it would be potentially quite difficult to implementefficient searching. This is why several subclasses of keyed referenceshave been implemented. A category bag on a Business Entity isrepresented by one or more child objects of the classeuBusinessEntityCategoryKeyedReference. This makes it easy to implementan efficient search for business entities with a specified keyedreference in their category bags.

[0258] The example below shows the abstract class and one of the derivedclasses, the euBusinessEntityCategoryKeyedReference, as discussed above.Note that the key to the keyed reference is inherited from the abstractclass, while the TModel key, key, name, and key value are all specifiedin the derived class, so they may have distinctive names for searching.set object-class uddiObjectClass:201 = { # abstract class as parent forall keyed references  name = euKeyedReference  subclass-of top must-contain   euKeyedReferenceKey }; set object-classuddiObjectClass:301 = { # Business Entity category keyed reference -collection makes up the category bag  name =euBusinessEntityCategoryKeyedReference  subclass-of euKeyedReference must-contain   euBusinessEntityCategoryTModel,  euBusinessEntityCategoryKeyName,   euBusinessEntityCategoryKeyValue };

[0259] The contact is a complex object, representing a wide variety ofinformation. Much like the Business Entity, a contact holds a variety ofcompound repeating elements, necessitating the use of child objectclasses.

[0260] The only data elements that are directly part of the contactobject are a key, and the name of the person or role the contactrepresents. There is an optional use-type.

[0261] All the other possible elements are children of the contactobject. These are: Address (parent of an ordered list of address-lineobjects, each with a key, use-type, sort code, and TModel key); Phone (aphone number plus use-type); E-mail (an e-mail address plus use-type);and Description (description string plus language code)

[0262] Again, although FIG. 15 illustrates an example of theintroduction of a hierarchy into a sub-structure according to anembodiment of the present disclosure for the representation of arelatively complex object in a Business Entity, it is equallyillustrative of an example of the introduction of a hierarchy into asub-structure according to an embodiment of the present disclosure forthe representation of a relatively complex object in a contact object.The Business Entity 151 of FIG. 15 is equally applicable to a contactobject, with the multi-valued elements of the contact object representedas children 152, 153 of the contact object 151. There may be none ormore children.

[0263] Another issue involves representing the names and descriptions(specified in the UDDI Standard) in an efficient manner, and allowingrapid searching for a specific type of name or description.

[0264] According to an embodiment of the present disclosure, the systemcreates an abstract base class to represent names, and another torepresent descriptions, and subclass them for each of the desired types.Search for the attributes of the subclass when looking for a specifictype of name (Business Entity name, for example), and for the abstractclass when looking for any name.

[0265] Several of the major objects (Business Entities, BusinessServices, etc) have the option of multiple names and descriptions. Thereasons are manifold. It is not uncommon for a business to be known bymultiple names, perhaps one formal and one or more colloquial. Moreover,a business may use different names in different languages. It is notuncommon for a name to translate badly, for example. For example, thecomputer firm Fujitsu used the name Facom in English-speaking countriesfor many years. The issue may exacerbated in languages with multiplecharacter sets. A Japanese firm may well have one version of their namein katakana, and another version in hiragana.

[0266] For these reasons and more, both name and description objects mayoccur multiple times for a single object. Each instance is tagged with alanguage code. In UDDI version 3 there may be multiple instances withthe same language code (this is not allowed in version 2).

[0267] Find qualifiers add further confusion. As mentioned earlier, UDDIsearches are required to support both case-sensitive andcase-insensitive searching, and this is best handled by storing the datatwice in the X.500 Directory.

[0268] The example, below shows the abstract class and one of thederived classes, euBusinessEntityName, used for the collection of namesof a Business Entity: set object-class uddiObjectClass:202 = { #abstract class as parent for all names  name = euName  subclass-of top must-contain   euNameKey  may-contain   euLanguage }; set object-classuddiObjectClass:331 = { # name of a Business Entity  name =euBusinessEntityName  subclass-of euName  must-contain  euBusinessEntityNameValue,   euBusinessEntityNameValueIC  # inheritseuNameKey and euLanguage from euName };

[0269] Note that the euBusinessEntityNameValue is the attribute thatcontains the case-sensitive version of the name; while theeuBusinessEntityNameValueIC is the version marked as “ignore case”, andis thus case-insensitive. The euNameKey field, inherited from theabstract class, is used to control the ordering of the names, andprovides a unique naming attribute.

[0270] An example of a name object might be:

euNameKey=890abcde-890a -890a -890a -890abcdef123

euLanguage=EN

euBusinessEntityNameValue=McKenna's Validation Systems

euBusinessEntityNameValueIC=McKenna's Validation Systems

[0271] Again, although FIG. 15 illustrates an example of theintroduction of a hierarchy into a sub-structure according to anembodiment of the present disclosure for the representation of arelatively complex object in a Business Entity, it is equallyillustrative of an example of the introduction of a hierarchy into asub-structure according to an embodiment of the present disclosure forthe representation of a relatively complex object in an abstract class.The Business Entity 151 of FIG. 15 is equally applicable to an abstract,with the multi-valued elements of the Binding Template represented aschildren 152, 153 of the abstract class 151. There may be none or morechildren.

[0272] Another issue relates to creating an efficient implementation ofthe requirement that a user be permitted to alter only those businessentities under his/her control. According to an embodiment of thepresent disclosure, this can be achieved by making the business entitiescontrolled by a user's children of the user object. This makes securitymore easily implemented.

[0273] It may be important to ensure that a publishing user only bepermitted to alter the information that he/she owns. It is possible todo this with various designs. However, the optimal design makes itimmediately clear whether a user is authorised to publish an item: allthe data controlled by a given user is located in that user's subtree.

[0274] This design decision has no impact on the ease of access tobusiness entities as a whole, because all inquiries into businessentities can be conducted from above the user level in the hierarchywithout loss of generality or performance.

[0275] Another issue relates to creating an efficient implementation ofPublisher Assertions, particularly with regard to the implementation ofthe findRelatedBusiness method. According to an embodiment of thepresent disclosure, this can be achieved by making the PublisherAssertions relating to a business children of the business object. Thiseliminates the need to search for that criterion.

[0276] One primary use of Publisher Assertions lies in thefind_RelatedBusinesses inquiry. This inquiry specifies a particularBusiness Entity, and requests information about all business entitiesrelated to that entity by completed Publisher Assertions. This inquiryis simplified, and accelerated, by a hierarchy which places thePublisher Assertions under the Business Entity to which they relate.This has the added benefit of increasing consistency. When a BusinessEntity is deleted all the associated Publisher Assertions (nowirrelevant) are deleted with it.

[0277] Another issue relates to creating an efficient implementation ofthe requirement that a user be permitted to alter only those TModelsunder his/her control. According to an embodiment of the presentdisclosure, the system makes the TModels, defined by a user, children ofthe user object. This makes security easy to implement.

[0278] For reasons similar to those that governed the placing ofbusiness entities under user entries, it is sensible to placeuser-defined TModels under the user entry of the user who defines them.There is no detrimental impact on locating the TModels, since they canbe located via a single indexed access, because all TModels are uniquelynamed.

[0279] Another issue relates to implementing efficient searching ofPublisher Assertions by relationship. According to an embodiment of thepresent disclosure, this can be achieved by making the relationshipkeyed reference an auxiliary class of the Publisher Assertion entry. Ifthe keyed reference were a child (one implementation) it could not besearched with equal efficiency, and searches for the relationship couldnot be combined with searches on the content of the Publisher Assertion,such as the (critical) filter on status (only completed assertions areconsidered).

[0280] The X.500 schema system may not support the construction ofobject classes that include other object classes as data elements. Forexample, a keyed reference can not be a data element of a PublisherAssertion. It is possible to make the keyed reference a child of thePublisher Assertion, but this does not facilitate the construction of anefficient search that references the contents of the keyed reference.

[0281] Making the keyed reference an auxiliary class to the PublisherAssertion entry is an efficient solution to the problem. It is thenpossible to search on the content of the keyed reference as though itwere part of the assertion.

[0282] As described above, an example of a Publisher Assertion might be:

euPublisherAssertionKey=7890abcd-7890-7890-7890-7890abcdef12

euFromBusinessKey=34567890-3456-3456-3456-34567890abcd

euFromUserKey=23456789-2345-2345-2345-234567890abc

euToBusinessKey=09876543-6543-6543-6543-dcba09876543

euToUserKey=98765432-5432-5432-5432-cba098765432

euPublisherAssertionStatus=status:complete

euPublisherAssertionTModel=uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

euPublisherAssertionKeyName=wholly-owned subsidiary

euPublisherAssertionKeyValue=parent-child

[0283] The auxiliary object class is euPublisherAssertionKeyReference,and the last three attributes listed above are the data elements of thatclass.

[0284] According to an embodiment of the present disclosure, a Directorysuch as eTrust™ Directory by Computer Associates may be utilized toimplement an ideal enterprise UDDI registry platform. eTrust Directory,which is a fully compliant LDAPv3, X.500 electronic Directory, can beused to underpin a UDDI Web Services implementation. The ‘eTrust’Directory allows the UDDI implementation to leverage the highly matureDirectory solution that is well proven in large-scale, business-criticalDirectory service applications.

[0285] There are many unique features of ‘eTrust’ Directory that make itextremely attractive as a platform on which to build a UDDI registry.Some of these include: Security features including access controlpolicies, roles, secure proxy, mutual authentication, distributedauthentication, distributed SSL certificate subject verification andnetwork address validation; Distribution and routing capabilitiesincluding parallel-distributed searches, load sharing, query streamingand shortest path routing; A multi-master replication scheme thatcombines the speed and efficiency of replay-based mechanisms (known asmulti-write) with state-based recovery and reconciliation techniques;Availability features including hot swap of data-bases, networkfail-over and Directory System Agent (DSA) fail over; Caching designthat is considered fast; and Deployment features including dynamicconfiguration (of data types, schema rules, security, knowledge and soon), unlimited data size, general information integrity rules, extensiveadministrative controls and an interactive command console.

[0286] eTrust Directory provides a proven X.500 Directory solution. Ontop of this proven foundation can be implemented a UDDI Semantic Bridgeto enable a fully Standards-compliant UDDI Registry. Because of thecapabilities of the underlying Directory solution, the embodimentsdisclosed herein can deliver flexible security, distribution andmanageability without requiring changes or extensions to the existingUDDI Standards.

[0287] One issue of the present embodiment deals with how to maprelationships between entities stored in disparate sections of theDirectory.

[0288] While UDDI data structures are primarily hierarchical, there maybe a problem with cross relationship between different objects.

[0289] There are essentially two categories of relationships, namelyalternative names, and cross relationships. According to an embodimentof the present disclosure, the problem is resolved by making use of theconcept of Aliases to address the alternative names. Essentially thishas the effect to ‘attach’ a foreign entity as a virtual child of theprimary entity.

[0290] The present embodiment makes use of unique keys to address theproblem of cross relationships. Essentially this has the effect ofcreating ‘relationship pointers’ rather like the Primary/Foreign keysystem in RDBMS technology to model relationships between data entitiesthat exist between disjoint sub-tress within a hierarchical Directorysystem.

[0291] The use of aliases according to embodiments of the presentdisclosure will now be described. A first scenario is most clearlydemonstrated by the implementation of UDDI Business Service Projections.A Business Service projection is in effect an alternative name for aBusiness Service. A Business Service Projection is a Business Servicewhich appears to belong to Business A, but which is in fact owned anddefined by Business B.

[0292] Referring to FIG. 5, Business Service 51, a Service owned byBusiness A, appears also to belong to Business B. Any changes made byBusiness A to Business Service 51 will be reflected in the projectedService appearing under Business B. Similarly, if Business Service 51 isdeleted from the registry, it will no longer appear under eitherBusiness A or Business B. Additionally, Business Entity B may not editor change Business Service 51. For editing and all other Publishingpurposes, only Business A has access to Business Service 51.

[0293] A Directory Alias system can be utilised to achieve this effect.An alias of Business Service 51 is added to Business Entity B. The aliasis a special marker for the Directory server which says in effect ‘whensomeone looks at this alias, show them this other entry over here’.

[0294] It means that when the original Service is edited, the changeswill be visible in the projection as well. If the Directory systemsupports Alias integrity, which is the case with eTrust Directory, ifthe service is deleted, the projection will automatically be removed aswell.

[0295] In addition, the Directory server can be configured to show theprojected Business Service twice when it is searched for, once undereach parent. This can be useful when doing searches which need toresolve the parents of a Business Service.

[0296] Some situations require that objects in disjoint parts of theDirectory hierarchy maintain a relationship.

[0297] An example of this is between Binding Templates and TModels.TModels are used throughout UDDI for various purposes. They arecategorization keys, search identifiers, (UDDI) relationshipdescriptors, and in this instance, technical specification‘fingerprints’. A TModel which is ‘attached’ to a BindingTemplatedescribes a technical specification to which that BindingTemplate (seeFIG. 8) conforms. For example, a publisher might attach a TModelasserting that their Binding Template conforms to the SOAP 1.1 Standard.

[0298] A registry typically contains a finite set of TModels, many ofwhich will be referenced by hundreds or even thousands of BindingTemplate entries. In some cases the registry will return the details ofany ‘attached’ TModels with the details of the BindingTemplate.

[0299] According to this embodiment of the present disclosure, aprimary/foreign key system such as that utilized in relational databasesystem can be suitably modified and applied. Every TModel stored in theregistry has its own unique (primary) key. A Binding Template referencesa TModel by adding a local (foreign) key which matches the unique key ofthe required TModel. FIG. 7 illustrates an example of this. The servercan then look up the TModel in question if TModel data is needed to bereturned with the Binding Template.

[0300]FIG. 6 shows the relationships between a Binding template andTModel.

[0301]FIG. 7 shows how the TModel key creates the relationship betweenthe two entities.

[0302] A Publisher Assertion is an important element of a UDDIrepository. As noted above, it provides users with the ability todiscover which business entities are related to a Business Entity ofinterest, and how they are related.

[0303] The Publisher Assertion was designed to protect against abuse,with an asserted relationship only becoming visible when the owners ofboth business entities involved had asserted the relationship. Thisprotection comes at a cost, in that it complicates the implementation,and necessitates careful design to avoid poor performance.

[0304] One problem is integrity. A Publisher Assertion has a morecomplex lifecycle than any other UDDI construct. It comes into beingwhen the owner of a Business Entity makes an assertion about thatbusiness and its relationship to another Business Entity. The owner ofthe other Business Entity can request a status report and discover whatassertions have been made about their businesses, or they may benotified out-of-band. Either way, the owner of the other Business Entitycan choose to make a matching assertion about the relationship betweenthe two business entities. At that moment the assertion is complete, andvisible to users calling findRelatedBusinesses. One or both assertionscan be modified or deleted, and the assertion becomes incomplete again,and should no longer be visible. Additionally, the deletion of eitherBusiness Entity should immediately remove the assertion.

[0305] The Publisher Assertion objects may be managed in a manner thatmaintains integrity of the assertion.

[0306] It is desirable that the owner of a Business Entity be able tomake (and remove) assertions about the business entities controlled bythat owner.

[0307] This embodiment of the present disclosure is predicated upon theassumption that the UDDI repository will be a “read-mostly” store, muchas intended for an x.500 Directory. To this end, the design is optimizedfor better read performance, even at the cost of imposing a heavierburden on writes.

[0308] An object class called Publisher Assertion is designed to holddata beyond that required by the UDDI Standard, because of thedesirability to optimize search performance. The design introduces anoperational attribute, which defines the Publisher Assertion status. Thestatus of the assertion is determined at the time of writing to theDirectory and in this way need not be determined each time a search isperformed.

[0309] The present embodiment also uses Pointers in the form of UserKeys. When a Publisher Assertion is written to the Directory the userkeys for the “to” and “from” businesses are determined and written intothe object. This simplifies the getAssertionStatusReport query, becauseall that is required to generate such a report is to search for aPublisher Assertion that contains the user key of the person who isgenerating the report.

[0310] In contrast, there would be considerable effort required togenerate the report if it was necessary to query all the business keysunder the user, then look for Publisher Assertions containing thosebusiness keys.

[0311] One common use of Publisher Assertions is for the discovery ofthose businesses ‘related’ to a given business. To provide goodperformance for that query, the Publisher Assertion(s) relating to abusiness are placed as child node(s) of the business.

[0312] In addition, the status of each assertion is recorded in theassertion as an operational attribute. This makes it is possible toquery just the Publisher Assertions with a status of complete locatedbeneath the company of interest. This simplifies the search forfindRelatedBusinesses because the search will recall only thoseassertions which are complete.

[0313] To simplify security, all businesses controlled by a user andtheir Publisher Assertions may be child nodes under that user's accountentry. This implementation enforces access control by only allowing aUser access to the sub-tree under the User's account entry.

[0314] Note that the operational attribute representing the status ismanaged by the UDDI implementation. When a user publishes an assertionwhich has already been asserted by another asserted business, the UDDIimplementation will update the status of the other assertion, which isin another sub-tree controlled by the User of the other business. Theaccess controls allow for this.

[0315] As an alternative embodiment to storing two Publisher Assertionobjects, one under each of the two Business Entities involved, a singlePublisher Assertion object is provided in it's own sub-tree. Forexample, the Publisher Assertion sub-tree can be provided underRepository object(s). When the assertion is initially stored in thiscase, it is given an incomplete status (for example, tokeyincomplete orfromkeyincomplete, depending on which side asserted it). If thePublisher Assertion is asserted by a complementary user, the status ischanged to complete. If the Publisher Assertion is deleted by one of thetwo, then the status is changed back to incomplete. If the PublisherAssertion is deleted by both sides, then the Publisher Assertion objectis deleted. Advantageously, this results in just one copy of anassertion, and most of the maintenance work consists of doing a modifyof the single attribute that holds the status of the assertion.

[0316]FIG. 12 illustrates schematically a hierarchy according to anembodiment of the present disclosure. The schematic illustrates bothalternatives, where the Publisher Assertion object is placed underBusiness Entity and/or Repository object.

[0317]FIG. 8 illustrates a method to request to add a PublisherAssertion. In Step S80, a determination is made whether the request isvalid. If not valid (No, Step S80), the request fails (Step S92). If therequest is valid (Yes, Step S80), a determination is made whether therequest is from business ours (Step S82). If it is not from businessours (No, Step S82), a determination is made whether it is to businessours (Step S84). If not to business ours (No, Step S84), the requestfails (Step S92). If it is to business ours (Yes, Step S84), adetermination is made whether the assertion is made by from owners (StepS86). If the assertion is not made by from owner (No, Step S86), anincomplete assertion is written (Step S94). If the assertion is made byfrom owner (Yes, Step S86), the complete assertion is written (StepS96). Returning to Step S82,m if it is determined that the request isfrom business ours (Yes, Step S82), a determination is made whether itis to business ours (Step S88). If not to business ours (No, Step S88),a determination is made whether the assertion is made by to owner (StepS90). If the assertion is not made by the to owner (No, Step S90), theincomplete assertion is written (Step S94). If the result of Step S88 isYes (To business ours), or the result, of Step S90 is Yes (assertionmade by To owner), the complete assertion is written (Step S96).

[0318] The next issue deals with how to optimize construction ofintermediate, search result collections during search operations so thatboth Directory access and iterative, in-memory operations are minimized,taking into account the Directory storage medium limitations. Inpractice, Directory entries may be stored and returned in arbitraryorder, and Directory results may be too large to sort.

[0319] According to an embodiment of the, present disclosure, anobject-oriented in-memory data storage system coupled with a uniqueresult sorting scheme which sorts intermediate results by DistinguishedName is provided. This allows one search to return many different typesof objects—BusinessEntities, BusinessServices, etc—and still allows thesystem to easily construct the correct XML structure for returning thedata to the user. It is to be noted that Web Service interactions are inXML.

[0320] A description of such a system will now be described. A UDDIBusinessEntity and any child data elements in the present disclosure arerepresented (partially) in the Directory according to the followinghierarchy:

[0321] BusinessEntity

[0322] BusinessService

[0323] BindingTemplate

[0324] BindingTemplate

[0325] ServiceName

[0326] ServiceName

[0327] BusinessService

[0328] BindingTemplate

[0329] BindingTemplate

[0330] ServiceName

[0331] ServiceName

[0332] BusinessName

[0333] BusinessName

[0334] BusinessDescription

[0335] BusinessDescription

[0336] Note that ServiceName, BusinessName and BusinessDescription havebeen described in relation to aspects of the present disclosure dealingwith Substructures and Object Splitting.

[0337] The BusinessEntity retrieval code performs a Directory SubTreesearch based upon the unique key of the required Business Entity orbusiness entities. This search will return the entries found, plus allsub-entries. The Directory Standards do not guarantee any particularorder to the returned entries—or even that sub-entries will immediatelyfollow their parent entry.

[0338] Therefore, the retrieval code then sorts the returned entries byDistinguished Name. This guarantees that sub-entries will be orderedafter their parents, and that parent-child relationships can easily bedistinguished. A variety of sorting algorithms can be used. The sortingalgorithm used should exhibit characteristics of high performance in thecase where entries are partially sorted.

[0339] The algorithm for results construction is essentially inoperation a ‘depth-first, left-to-right tree-walk’. It is otherwiseknown in graph theory as a ‘postorder traversal’.

[0340] The sorted list is passed to the constructor method of a newBusinessEntity object. This object may be, for example, anobject-oriented programming construct designed to represent a UDDIBusiness Entity. The BusinessEntity object contains the code to‘construct itself’ from the data provided in the entry last. The codemoves iteratively through the list, making decisions about each entry.It is understood that the first entry in the list should be the mainentry for the Business Entity itself, and as soon as it finds anotherBusinessEntity it is understood that construction has finished—theordering of the list guarantees this. As soon as it finds aBusinessService or other child entry, an object of the appropriate typeis instantiated and the list is passed to the new object's constructor,along with a pointer telling it where to start in the list.

[0341] Each object contains essentially similar processing code tohandle construction of itself and delegate construction of any childentries to appropriate child objects.

[0342] In this way, only a single Directory search need be performed,and the resulting list is handled in an efficient fashion, with everyentry being processed once. If the list was left in an arbitrary order,or sorted in some other fashion, the list would have to be processed inmultiple passes to correctly construct a UDDI hierarchy from theresulting entries.

[0343] Delegation of construction and list processing to the differentprogramming objects in the hierarchy keeps the processing code to acomparatively small size, making it more efficient and ultimatelyfaster.

[0344]FIG. 9 illustrates programming constructs (objects), including arepresentation of the sorted entry list. A determination is made whetherthere are any further items in a list of items. If there are noadditional items (No, Step S100), the process exits (Step S118). Ifthere are additional items (Yes, Step S100), the next item in the listis retrieved (Step S102). A determination is then made whether the itemis of this object type. If the item is of this object type (Yes, StepS104), the object attributes are set based on the item (Step S106) andthe process returns to Step S100. If it is not of this object type (No,Step S104), a determination is made whether an item of this object typehas been processed yet (Step S108). If the item of this object type hasnot yet been processed (No, Step S108), the process returns to StepS100. If an item of this object type has been processed (Yes, StepS108), a determination is made whether the item is an intrinsiccomponent of this object (e.g., Name, Description, etc.). If it is anintrinsic component (Yes, Step S110), the item is added to the objectattribute and extra processing may be performed (Step S112) and theprocess returns to Step S100. If it is not an intrinsic component (No,Step 110), a determination is made whether the item is a child object ofthis object (e.g., BusinessService if this is a BusinessEntity). If itis a child object (Yes, Step S114), the system instantiates an object ofthe correct type, and passes the list of items to a constructor (StepS116) and the process returns to Step S100. If it is not a child object(No, Step S114), the process returns to Step S100.

[0345] The following ‘real word’ example demonstrates the kind ofarbitrary ordering an LDAP Directory might be expected to return.SearchResultEntry  objectName:businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA  attributes   type: objectClass   value:businessEntity   type: businessKey   value:1ba3034aeef738da00eef78599fe0004 SearchResultEntry  objectName:descriptionKey=1ba3034aeef738da00eef786302b0008,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: uddiDescriptionSearchResultEntry  objectName:serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: businessServiceSearchResultEntry  objectName:nameKey=1ba3034aeef738da00eef78970da000d,serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA  attributes   type: objectClass   value:businessServiceName SearchResultEntry  objectName:bindingKey=1ba3034aeef738da00eef7899fb7000e,serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba303 4aedb9154900edb915491c0001,o=CA  attributes   type:objectClass   value: bindingTemplate SearchResultEntry  objectName:nameKey=1ba3034aeef738da00eef7862fe50007,businessKey=1ba3034aeef7 38da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: businessEntityName

[0346] List 1—The Name entry highlighted in bold is a leaf of theBusinessEntity entry at the top of the list, and it would be useful ifit appeared before the BusinessService entry and other branch-childrenof the BusinessEntity. However, it appears at the end of the list, whichforces any processing code to search the entire list to ensure alldirect children of the BusinessEntity have been processed. This may notbe the most efficient.

[0347] Accordingly, a version of the same data which has been sortedaccording to the rules formulated according to an embodiment of thepresent disclosure: SearchResultEntry  objectName:businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA  attributes   type: objectClass   value:businessEntity   type: businessKey   value:1ba3034aeef738da00eef78599fe0004 SearchResultEntry  objectName:descriptionKey=1ba3034aeef738da00eef786302b0008,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: uddiDescriptionSearchResultEntry  objectName:nameKey=1ba3034aeef738da00eef7862fe50007,businessKey=1ba3034aeef7 38da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: businessEntityNameSearchResultEntry  objectName:serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA attributes   type: objectClass   value: businessServiceSearchResultEntry  objectName:bindingKey=1ba3034aeef738da00eef7899fb7000e,serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba303 4aedb9154900edb915491c0001,o=CA  attributes   type:objectClass   value: bindingTemplate SearchResultEntry  objectName:nameKey=1ba3034aeef738da00eef78970da000d,serviceKey=1ba3034aeef738da00eef789707f000c,businessKey=1ba3034aeef738da00eef78599fe0004,userKey=1ba3034aedb9154900edb915491c0001,o=CA  attributes   type: objectClass   value:businessServiceName

[0348] List 2—The entry highlighted in bold now appears in a morelogical place in the list, and processing code can now be written totake advantage of this. When the number of entries is increased torealistic server loads, the savings on processing time can beconsiderable.

[0349] The following is another embodiment of the present disclosure.

[0350] # schema for representing UDDI data and/or relationships in aDirectory . . . expression 100

[0351] # Computer Associates eTrust UDDI Configuration Schema

[0352] # Copyright (c) 2002 Computer Associates Inc

[0353] set oid-prefix uddiAttributeType=(1.3.6.1.4.1.3327.80.1);

[0354] set oid-prefix uddiObjectClass=(1.3.6.1.4.1.3327.80.2);

[0355] set oid-prefix uddiBinding=(1.3.6.1.4.1.3327.80.3);

[0356] ______

[0357] {# description under binding template

[0358] name=euBindingTemplateDescription-euBindingTemplate

[0359] euBindingTemplateDescription allowable-parent euBindingTemplate

[0360] named-by euDescriptionKey

[0361] };

[0362] schema set name-binding uddiBinding:510=

[0363] {# tmodel instance info under binding template

[0364] name=euTModelInstanceInfo-euBindingTemplate

[0365] euTModelInstanceInfo allowable-parent euBindingTemplate

[0366] named-by euInstanceTModelkey

[0367] };

[0368] schema set name-binding uddiBinding:601=

[0369] {# description under tmodel instance info

[0370] name=euTModelInstanceInfoDescription-euTModelInstanceInfo

[0371] euTModelInstanceInfoDescription allowable-parenteuTModelInstanceInfo

[0372] named-by euDescriptionKey

[0373] };

[0374] schema set name-binding uddiBinding:602=

[0375] {# instance details description under tmodel instance info

[0376] name=euTmodelInstanceDetailsDescription-euTModelInstanceInfo

[0377] euTmodelInstanceDetailsDescription allowable-parenteuTModelInstanceInfo

[0378] named-by euDescriptionKey

[0379] };

[0380] schema set name-binding uddiBinding:603=

[0381] {# overview doc description under tmodel instance info

[0382] name=euOverviewDocDescription-euTModelInstanceInfo

[0383] euOverviewDocDescription allowable-parent euTModelInstanceInfo

[0384] named-by euDescriptionKey

[0385] };

[0386] As the present disclosure may be embodied in several formswithout departing from the spirit of the essential characteristics ofthe disclosure, it should be understood that the above describedembodiments are not to limit the present disclosure unless otherwisespecified, but rather should be construed broadly within the spirit andscope of the disclosure as defined in the appended claims. Variousmodifications and equivalent arrangements are intended to be includedwithin the spirit and scope of the disclosure and appended claims.

What is claimed is:
 1. A Web Services directory comprising: at least oneBusiness Entity object; and at least one User object, wherein the atleast one Business Entity object is arranged under the at least one Userobject.
 2. The Web Services directory as recited in claim 1, furthercomprising: at least one Business Service object; and at least oneBinding Template object, wherein the at least one Business Serviceobject is arranged under the at least one Business Entity object, andthe at least one Binding Template object is arranged under the at leastone Business Service object.
 3. The Web Services directory as recited inclaim 1, wherein the at least one Business Entity object is arrangedunder the at least one User object by virtur of at least onecorresponding User Children object.
 4. The Web Services directory asrecited in claim 1, further comprising at least one Domain object,wherein the at least one User object is arranged under the at least oneDomain object.
 5. The Web Services directory as recited in claim 1,further comprising apparatus adapted to implement the Web Servicesdirectory, and in which Directory Services are invoked.
 6. The WebServices directory as recited in claim 5, wherein the Directory Servicesare invoked using at least one of X.500 and LDAP protocols.
 7. A WebServices system comprising: a registry in which businesses may register,the registry comprising a hierarchical directory including at least oneBusiness Entity object and at least one User object, the at least oneBusiness Entity object being arranged under the at least one Userobject; and a storage system for storing business information andaccessible via the hierarchical directory.